Bug 1770098 Comment 30 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

### Beta/Release Uplift Approval Request
* **User impact if declined**: Some users that have been experiencing an non-functional Firefox since FF100 came out in May will have to wait until the end of August for FF to work again
* **Is this code covered by automated tests?**: No
* **Has the fix been verified in Nightly?**: Yes
* **Needs manual test from QE?**: Yes
* **If yes, steps to reproduce**: 1. Navigate to "about:support"
2. Under Sandbox>Win32k Lockdown State for Content Process, verify the status is "Win32k Lockdown enabled ... "
3. Open the Start Menu and type "Exploit Protection"
4. Goto the "Program Settings" tab
5. Click "Add program to customize">"Add by program name"
6. Type "firefox.exe"
7. When the "Program settings" panel pops up, find "Simulate Execution (SimExec)"
8. Check the "Override system settings" and turn the slider to "On"
9. Restart firefox
10. Check the same area in "about:support" and verify that Win32k is now disabled due to incompatible exploit protection policies
* **List of other uplifts needed**: None
* **Risk to taking this patch**: Low
* **Why is the change risky/not risky? (and alternatives if risky)**: - Despite its large size, the change mostly does pretty mundane stuff (searching the registry for values and reducing them to a single yes/no answer), and the worst-case scenario is that Win32k Lockdown is incorrectly disabled compatible machines (extremely unlikely), or that it's incorrectly enabled on incompatible machines (which is already the case anyhow)
* **String changes made/needed**: 
* **Is Android affected?**: No
### Beta/Release Uplift Approval Request
* **User impact if declined**: Some users that have been experiencing an non-functional Firefox since FF100 came out in May will have to wait until the end of August for FF to work again
* **Is this code covered by automated tests?**: No
* **Has the fix been verified in Nightly?**: Yes
* **Needs manual test from QE?**: Yes
* **If yes, steps to reproduce**: 1. Navigate to "about:support"
2. Under Sandbox>Win32k Lockdown State for Content Process, verify the status is "Win32k Lockdown enabled ... "
3. Open the Start Menu and type "Exploit Protection"
4. Goto the "Program Settings" tab
5. Click "Add program to customize">"Add by program name"
6. Type "firefox.exe"
7. When the "Program settings" panel pops up, find "Simulate Execution (SimExec)"
8. Check the "Override system settings" and turn the slider to "On"
9. Restart firefox
10. Check the same area in "about:support" and verify that Win32k is now disabled due to incompatible exploit protection policies
11. Don't forget to undo adding "firefox.exe" to Exploit Protection on your QA machine!
* **List of other uplifts needed**: None
* **Risk to taking this patch**: Low
* **Why is the change risky/not risky? (and alternatives if risky)**: - Despite its large size, the change mostly does pretty mundane stuff (searching the registry for values and reducing them to a single yes/no answer), and the worst-case scenario is that Win32k Lockdown is incorrectly disabled compatible machines (extremely unlikely), or that it's incorrectly enabled on incompatible machines (which is already the case anyhow)
* **String changes made/needed**: 
* **Is Android affected?**: No

Back to Bug 1770098 Comment 30